Thanks for opening a pull request and helping make RubyGems and Bundler better! Someone from the RubyGems team will take a look at your pull request shortly and leave any feedback. Please make sure that your pull request has tests for any changes or added functionality.

We use GitHub Actions to test and make sure your change works functionally and uses acceptable conventions, you can review the current progress of GitHub Actions in the PR status window below.

If you have any questions or concerns that you wish to ask, feel free to leave a comment in this PR or join our #rubygems or #bundler channel on Slack.

For more information about contributing to the RubyGems project feel free to review our CONTRIBUTING guide

Hi @Vasfed, thanks for the work on fixing this!

My first idea for the fix was something a bit different. It was doing it in two steps:

• For next patch level version, fix this by rescuing permission errors when finding the temporary directory in Bundler.user_home, and in that case, fallback to the real user home, even if it's unwritable. If Bundler ever needs to actually write to it, we'll get a permission error, which will be expected in readonly systems. Otherwise, things will just work, not only when checking plugins, but whenever this fallback actually happens.

• For next version allowing minor breaking changes, completely remove the fallback to a temporary user home. Always return the real home, and print a warning if it's not writable. In many years, I've never seen this fallback actually used, and I believe it causes more harm than good.

What do you think?

Hi @deivid-rodriguez at first only rescuing the exception was my first idea too, but in this case there're several warnings to stdout/stderr (from ruby itself and bundler).
Revisiting this - and indeed, I agree with you, for the patch version changes can be lesser - will change the PR accordingly.

About breaking changes - me too never encountered when tmp home is needed and there's no workaround. As for warning - may be print it only if an exception actually occurs

Changed to only rescue exception

Sorry for the delay @Vasfed. This looks great!

I rebased and made one change to convert the spec to a workflow that runs Bundler on a read-only system. The rationale being that the kind of test added in rubygems/bundler#6482 did not catch the issue introduced with Ruby 3.4, so I prefer to switch to something more realistic that will prevent the problem from being reintroduced in the future.

Thanks so much @Vasfed!